Formal object oriented development of software systems using LOTOS

i Abstract Formal methods are necessary in achieving correct software: that is, software that can be proven to fulll its requirements. Formal speciications are unambiguous and analysable. Building a formal model improves understanding. The modelling of nondeterminism, and its subsequent removal in formal steps, allows design and implementation decisions to be made when most suitable. Formal models are amenable to mathematical manipulation and reasoning, and facilitate rigorous testing procedures. However, formal methods are not widely used in software development. In most cases, this is because they are not suitably supported with development tools. Further, many software developers do not recognise the need for rigour. Object oriented techniques are successful in the production of large, complex software systems. The methods are based on simple mathematical models of abstraction and classiication. Further, the object oriented approach ooers a conceptual consistency across all stages of software development. However, the inherent exibility of object oriented approaches can lead to an incremental and interactive style of development, a consequence of which may be insuucient rigour. This lack of rigour is exacerbated by the inconsistent and informal semantics for object oriented concepts at all stages of development. Formal and object oriented methods are complementary in software development: object oriented methods can be used to manage the construction of formal models and formality can add rigour to object oriented software development. This thesis shows how formal object oriented development can proceed from analysis and requirements capture to design and implementation. A formal object oriented analysis language is deened in terms of a state transition system semantics. This language is said to be customer-oriented: a number of graphical views of object oriented relations in the formal analysis models are presented, and the speciications produced say what is required rather than how the requirements are to be met. A translation to ACT ONE provides an executable model for customer validation. This translation is founded on a precise statement of the relationship between classes and types (and subclassing and subtypes). The structure of the resulting ACT ONE requirements model corresponds to the structure of the problem domain, as communicated by the customer. The step from analyis to design requires an extension to the requirements model to incorporate semantics for object communication. A process algebra provides a suitable formal model for the speciication of communication properties. LOTOS, which combines ACT ONE and a process algebra in one coherent semantic model, provides …